Activity: Detail the Software Requirements

Purpose To collect, detail and organize the set (package) of artifacts that completely describe the software requirements of the system or subsystem.
Steps Collect Software Requirements Artifacts Detail the Software Requirements Generate Supporting Reports Assemble the Software Requirements Specification
Checkpoints Software Requirements Specification Use Case Supplementary Specifications Requirements Attributes
Input Artifacts: Vision Glossary Use-Case Model Use Case Supplementary Specifications Requirements Attributes Requirements Management Plan User-Interface Prototype	Resulting Artifacts: Requirements Attributes, updated Supplementary Specifications, detailed Software Requirements Specification
Worker: Use-Case Specifier
Tool Mentors: Creating a Use-Case Model Survey using SoDA Creating a Use-Case Report using SoDA
More Information: Guidelines: Software Requirements Specification Concepts: Requirements Concepts: Requirement Types Concepts: Requirements Management Concepts: Traceability

Workflow Details:

Core Workflow: Requirements

Refine the System Definition

Collect Software Requirements Artifacts

The Software Requirements Specification (SRS) focuses on the collection and organization of all requirements surrounding your project. Refer to the Requirements Management Plan to determine the correct location and organization of the requirements. For example, it may be desired to have a separate SRS to describe the complete software requirements for each feature in a particular release of the product. This may include several use cases from the system use-case model, to describe the functional requirements of this feature, along with the relevant set of detailed requirements in Supplementary Specifications.

Since you might find yourself with several different tools for collecting these requirements, it is important to realize that the collection of requirements may be found in several different artifacts and tools. For example, you might find it appropriate to collect textual requirements such as non-functional requirements, Design Constraints, etc, with a text documenting tool in Supplementary Specifications. You might find it useful to collect some (or all) of the functional requirements in the use cases and you might find it handy to use a tool appropriate to the needs of defining and diagramming the use-case model. It is helpful to utilize a requirements management tool to assist with specification, organization and traceability of the requirements.

Detail the Software Requirements

Make sure that all requirements are specified to the level of detail needed to hand off to designers, testers and documentation writers. Review the Checkpoints: Software Requirements Specification and Checkpoints: Supplementary Specifications to see if further detail is needed to capture any software requirements not included in the use cases. If specialized tools are not used for capturing the requirements (e.g. graphical use-case modeling tools), then all software requirements may be written directly in an SRS document.

Generate Supporting Reports

The Software Requirements Specification is used for collecting your project software requirements in a formal, IEEE 830-type document, represented by a UML ôpackageö construct. Two sample SRS templates are provided: one for use with use-case modeling (rup_srsuc.dot) and one for use without use-case modeling (rup_srs.dot). The first (rup_srsuc.dot) references, or encloses, the use-case-model artifacts: the use-case model survey, the use-case reports, and the supplementary specifications. This allows you to have a formal IEEE-compliant SRS without having to duplicate the information in these other 3 artifacts.

The second (rup_srs.dot) is an independent document which contains all the software requirements directly in the document. This document would require you to use traceability to use-case artifact requirements, if they are used. Technically, they both contain the same information, however the information in the use-case model is enclosed by reference (rather than being duplicated) in the first and fully duplicated (if using use cases) in the second, which would require much more effort in maintaining the traceability relationships.

What you need now is a collection, or package, of artifacts that describes the complete external behavior of the system - i.e., a package that says specifically, ôHere is what the system has to do to deliver those features.ö That is what we refer to as the SRS Package. Generate the Use-Case-Model Survey, Use-Case Reports and any other supporting documents or information to include in the Software Requirements Specification.

Assemble the Software Requirements Specification

Using the Software Requirements Specification template, assemble the pieces of the SRS package and supply the remaining information in order to have a complete definition of the software requirements for this subsystem or feature.